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Chapter  One 


INTRODUCTION 

PROJECT  BOLD  STROKE 


In  July  1985,  the  Assistant  Secretary  of  the  Air  Force  for 
Research,  Development  and  Logistics  wrote  to  the  Air  Force  Vice 
Chief  of  Staff  expressing  his  concern  about  software  problems 
adversely  affecting  the  Air  Force.  The  Assistant  Secretary 
concluded  with  a  remark  the  Air  Force  must  make  a  "bold  stroke" 
towards  a  remedy.  In  response,  the  Vice  Chief  commissioned  a 
study  team  to  survey  the  problem  and  report  its'  findings. 

Hence,  the  Air  Staff  Software  Management  Program  began,  commonly 
called  Project  Bold  Stroke  <12:100).  The  study  team  concluded 
its'  findings  with  four  objectives  and  accompanying  action  items 
issued  as  an  action  plan  to  Air  Force  major  commands  and  separate 
operating  agencies.  One  of  the  objectives,  "Training  and  Educa¬ 
tion,"  tasked  Air  University  to  develop  a  "short  <3-5  day) 
software  literacy  course"  for  "all  new  brigadier  general 
selectees"  and  "generals/sen ior  civilians  with  responsibility  for 
software"  (26:3). 


PURPOSE  OF  THIS  STUDY 


Given  the  above  tasking,  this  paper  reviews  the  literature 
and  highlights  the  problems  in  software  development.  It  posits  a 
list  of  topics  and  recommended  readings  for  the  course.  A  by¬ 
product  of  the  paper  is  a  summary  of  recent  thinking  on  the 
severe  technical  problems  facing  the  DOD  and  the  private  sector 
in  the  software  field. 

While  much  of  the  data  available  to  the  Bold  Stroke  team  is 
no  doubt  replicated  here,  the  objective  of  this  paper  is  dif¬ 
ferent.  By  way  of  analogy:  assume  Smith's  auto  headlights  do  not 
work  and  Jones  wants  to  borrow  Smith's  car.  Smith  can  either 
take  the  car  to  a  mechanic  or  advise  Jones  of  the  problem.  The 
mechanic  will  look  for  a  solution  to  the  problem.  Advising  Jones 
of  the  faulty  headlights  does  not  solve  the  problem  but  alerts 
J ones  to  the  hazards  of  driving  at  night.  As  applied  to  thi3 
paper,  the  Bold  Stroke  Team  was  looking  for  solutions  to  the 
software  crisis  whereas  this  paper's  objective  is  to  help  the 
students  avoid  common  pitfalls  while  they  oversee  the  software 
development  process.  Solutions  would  have  to  come  from  a  lengthy 


and  intensive  course,  beyond  the  scope  of  the  Bold  Stroke 
software  literacy  course. 


ASSUMPTIONS  AND  LIMITATIONS 

The  reader  must  be  familiar  with  software  concepts  and 
terminology  since  brevity  precludes  a  tutorial  approach.  Even 
for  the  knowledgeable  reader,  length  constrains  the  amount  of 
detail  that  can  be  presented  on  the  problems  in  software  develop¬ 
ment.  Only  the  highlights  appear.  An  in-depth  treatment  is 
available  through  the  citations  and  bibliography. 

Although  there  are  several  ways  to  classify  software,  e.g., 
by  host  hardware  or  by  function,  this  paper  assumes  only  two 
categories  of  software  with  only  one  significant  difference.  The 
scientific,  business,  administrative,  or  command  and  control 
software,  running  on  commercially  available  hardware,  will  be 
called  "ADP  systems."  "Embedded  software"  is  the  label  given  to 
software  operating  as  an  integral  part  of  a  system,  e.g.,  an 
avionics  package.  The  only  significant  difference  between  the 
two  is  in  the  procurement  process  because  the  principles  involved 
in  the  development,  maintenance  and  management  are  similar 
(38s 11) . 

This  study  will  not  argue  the  findings,  objectives  and 
taskings  of  the  Project  Bold  Stroke  Team.  Though  some  may  take 
issue  with  the  team's  conclusions  (32: — ),  it  is  not  the  purpose 
of  this  paper.  Today,  the  course  is  a  "go"  and  the  need  exists 
for  planning  the  instruction. 

It  would  seem  to  be  a  safe  assumption  that  general  officers, 
as  students  attending  this  course,  will  have  a  wide  breadth  of 
experience.  It  is  also  assumed  most  will  lack  experience  in 
software  development.  This  last  assumption  follows  from  the 
Project  Bold  Stroke  Team's  findings.  They  concluded  senior 
leaders  needed  an  increased  awareness  of  the  software  development 
problems. 


OVERVIEW 

Chapter  Two  introduces  the  idea  of  a  software  crisis  by 
showing  the  immensity  of  the  problem  within  the  DOD.  It  sum¬ 
marizes  the  Project  Bold  Stroke  initiatives  to  counter  the 
problem,  and  presents  the  specific  objective  and  tasking  for  the 
senior  management  software  course. 


Chapter  Three  highlights  the  problems  encountered  during  the 
software  system  life  cycle  as  documented  in  the  literature.  The 
issues  fall  into  three  categoriesi  concept  development,  system 
development,  and  system  deployment. 

The  literature  survey  shows  other  software  development 
problems  do  not  fit  into  the  above  three  categories.  One  common¬ 
ality  among  these  items  is  management  is  ultimately  responsible 
for  them.  Chapter  Four,  Management  Issues,  describes  these 
items. 

With  the  nature  of  the  software  crisis  introduced  and  the 
life  cycle  and  management  issues  explored,  Chapter  Five  assesses 
the  topics  for  the  course.  It  begins  with  a  few  preface  remarks 
and  ends  with  suggested  course  offerings. 

Lastly,  Chapter  Six  concludes  with  a  summary  and  a  series  of 
recommendations.  The  recommendations  include  the  course  topics 
(also  Appendix  A),  course  readings  (Appendix  B)  and  items  for 
further  research. 


Chapter  Two 


THE  SOFTWARE  CRISIS 

THE  PROBLEMS 


In  any  attempt  to  de-fine  the  problems  facing  the  Air 
Force  in  the  computer  area,  the  pervasiveness  of  the 
technology  becomes  immediately  and  readily  apparent. 
Practically  every  area  of  Air  Force  operation  today  is 
involved  with  some  facet  of  computer  technology.  The 
explosive  growth  in  the  use  of  the  technology  over  the 
past  twenty  years  has  been  segmented  and  largely 
unplanned  in  an  overall  sense  (30:9). 

This  quote  is  from  a  1970  report  on  the  Air  Force's  ability 
to  exploit  computer  technology.  The  point  to  underscore  is  how 
long  problems  have  been  studied  and  documented.  While  organ¬ 
izational,  hardware  and  software  problems  continue  to  impact  the 
Air  Force  today,  the  emphasis  has  shifted. 

There  have  been  many  organizational  changes  since  that 
report.  For  example,  the  original  ADP'ers  were  assigned  to  staff 
elements  and  each  staff  element  purchased  its'  own  hardware. 
Later,  the  Air  Force  created  the  "single  manager"  concept  in 
which  ADP  personnel  and  hardware  belonged  to  one  centrally 
controlled  organization.  This  organization  became  a  service 
facility  for  the  staff  elements.  The  most  recent  organizational 
change  has  been  the  merger  of  the  ADP  and  communications  fields 
under  the  control  of  HQ  Air  Force  Communications  Command. 

On  the  topic  of  hardware,  there  has  been  a  dramatic  change. 
Once,  the  hardware  to  software  cost  ratio  had  been  80  to  20. 

This  was  the  era  of  transistors  and  before  the  advent  of  high 
scaled  integrated  circuitry.  Now,  hardware  is  very  inexpensive 
compared  to  software  with  a  cost  ratio  of  20  to  80. 

The  lessening  costs  of  hardware  is  only  one  side  of  the  cost 
equation.  The  expense  and  prol i feration  of  software  has 
tremendously  influenced  the  cost  ratio.  For  example: 

1.  Software  costs  the  DOD  $4  -  8  billion  per  year 
according  to  a  1985  report  (37:2).  Some  predictions  say  embedded 
software  alone,  will  hit  *32  billion  by  1990  (39:9;  6:2541). 


2.  The  "Report  of  the  SECDEF  to  the  Congress  on  the 
FY85  Budget"  listed  160  key  programs.  Of  these,  75  percent  had  a 
significant  software  component  (24i2>. 

3.  F-16As,  in  1981,  "had  seven  computer  systems  with 
fifty  digital  processors  and  135,000  lines  of  code."  1986  F-16Ds 
have  "fifteen  computer  systems  with  300  digital  processors  and 
236,000  lines  of  code"  (5:49). 

4.  Weapon  systems  software  expenditures  account  for  5 
percent  of  the  total  Air  Force  budget.  It  will  increase  to  10 
percent  by  1990  <5: 46). 

5.  Software  is  the  limiting  aspect  in  both  mission 
critical  and  support  systems  applications.  The  demand  for 
software  far  exceeds  the  supply.  With  current  technology  the 
supply  to  demand  ratio  will  be  1  to  4  by  1990  (28:17). 

Clearly,  software  is  a  growing  portion  of  systems  and  budgets. 
Furthermore,  DOD  faces  severe  problems  with  developing,  main¬ 
taining,  and  managing  software: 

1.  The  DOD  wastes  4800  million  per  year  because  of  poor 
software  management  (12:100). 

2.  Of  10  systems  in  trouble  today,  7  were  in  trouble 
because  of  software  (29:2-2). 

3.  The  Pentagon's  IG  found  75  percent  of  the  software 
contracts  reviewed  had  management  problems  (15:2).  ' 

4.  "It  has  often  taken  the  military  services  as  long  as 
nineteen  years  to  get  software  into  systems  from  the  time  of  its 
conception"  (5:46). 

5.  The  Defense  Systems  Management  College  ranks  control 
of  software  cost  as  one  of  the  Armed  Forces  largest  management 
problems  (42:2). 

One  can  easily  discern  the  impact.  If  a  large  portion  of  the 
budget  and  a  deliverable  system  is  in  trouble,  operational 
readiness  can  suffer.  If  the  USAF  in  FY86  could  have  saved 
one-tenth  of  what  it  expected  to  spend  on  software,  it  could  have 
bought  26  more  F-16Ds  (5:51). 

Interestingly,  the  DOD  is  not  the  only  one  suffering  the 
software  crisis.  In  many  corpor at  ions ,  there  is  a  two-  to 
four-year  backlog  of  programming  requests.  One  bank  reported  a 
seven-year  wait.  When  the  waiting  time  is  this  long,  users  do 


not  submit  requests  -for  programming  support.  Researchers  call 
this  the  "invisible  backlog."  The  Sloan  School  of  Business 
attempted  to  measure  this  "invisible  backlog"  and  estimated  it  to 
be  168  percent  of  the  formal  backlog  (4:5-6).  Though  the  DOD  and 
the  private  sector  have  many  of  the  same  problems  there  are 
unique  aspects  to  DOD's  software  computing. 

Complexity,  size,  specialized  application,  and  managerial 
restraints  are  some  of  the  aspects  that  distinguish  DOD  computing 
from  private  industry.  Weather  forecasting  and  ballistic  tra¬ 
jectory  calculations  are  examples  of  complex  computing.  The  size 
of  these  software  programs  can  be  millions  of  instructions.  Size 
can  also  refer  to  the  costs  as  evidenced  by  the  dollar  figures 
cited  above.  Command  and  control,  avionics  fire  control  and 
inertial  navigational  guidance  systems  are  examples  of 
specialized  applications.  Managerial  restraints  can  be  procure¬ 
ment  regulations,  mandated  personnel  end-strengths,  and  budget 
cuts.  Adding  to  this  uniqueness  is  that  the  DOD  leadership  can 
change  abruptly  with  each  new  administration  (2:16;  31:12-13). 
Perhaps  it  is  these  unique  aspects  and  the  difficulty  in 
achieving  progress  that  has  influenced  the  DOD  to  do  several 
studies  on  the  software  crisis  <28: — ;  23: — ;  24: — ;  27: — ; 

33: — ;  29: — ;  30: — ). 

In  1982,  the  USAF  Scientific  Advisory  Board  was  studying  the 
application  of  advanced  electronics.  In  many  instances,  software 
was  a  notable  component  of  those  systems.  They  said  weapon 
system  cost,  availability,  lead  time,  utility  and  survivability 
would  increasingly  become  a  function  of  the  software.  "The 
software  impact  on  schedule,  cost  and  performance  may  become  the 
dominant  factor  in  fielding  advanced  technology  systems" 

(29:2-1).  Their  findings  led  to  a  1983  follow-up  devoted 
specifically  to  software  in  weapon  systems.  By  1985,  USAF  top 
management  became  involved  and  Project  Bold  Stroke  was  born. 


PROJECT  BOLD  STROKE 

Representatives  from  each  of  the  functional  areas  on  the  Air 
Staff  and  from  several  major  air  commands  made  up  the  survey 
team.  The  Air  Staff's  Chief  of  Education,  Directorate  of 
Personnel  Programs,  chaired  the  team.  The  direction  given  to  the 
team  was  to  investigate  problems  of  the  "avai 1 abi 1 i ty  of  exper¬ 
tise,  sufficiency  of  software  orientation  and  reliance  on  the 
enlisted  force"  (26:15).  They  surveyed  the  literature  and 
conducted  interviews.  Once  word  spread  of  their  investigation, 
they  received  many  unsolicited  opinions  from  the  field. 


In  August  1985,  the  team  briefed  its'  findings.  Primarily, 
they  found  a  need  for  greater  awareness  and  in-depth  expertise 
<26i 16|  5i47).  Having  determined  a  scope  to  the  problem,  they 
were  tasked  to  come  up  with  a  "bold  stroke”  towards  a  solution. 
They  made  their  recommendations  in  the  form  of  an  action  plan 
composed  of  four  objectivesi 

1.  Awareness  -  to  create  an  overall  Air  Force  awareness 
of  the  criticality  of  software  and  computer-based  technology  to 
information  and  mission  critical  systems. 

2.  Training  and  education  -  to  provide  the  training  and 
education  necessary  to  ensure  the  Air  Force  fully  uses  the 
potential  available  through  software  and  computer-based 
technology. 

3.  Personnel  -  to  survey  Air  Force  software  personnel 
requirements  and  develop  more  comprehensive  approach  to 
recruiting  and  managing  military  and  civilians  in  this  career 
area. 

4.  Future  planning  -  to  project  future  software 
personnel  requirements  with  emphasis  on  the  appropriate  mix  of 
officers,  civilians,  NCOs,  and  contractor  support. 

A  purpose  statement  and  a  series  of  required  actions  or 
tasks  supports  each  objective  in  the  action  plan.  The  basis  for 
this  paper  is  objective  two,  paragraph  "A",  hereafter  called  Task 
1 1— A.  Given  the  second  objective  above  and  the  "need  to  ensure 
that  personnel  working  directly  with  software  development, 
employment,  and  follow-on  support  are  properly  trained/educated 
in  their  responsibilities"  <26i3>.  Task  II-A  required  Air 
University  to  develop  a  software  literacy  course  as  quoted  in  the 
problem  statement,  Chapter  One.  Since  the  intent  links 
"literacy"  with  those  having  responsibilities  for  software 
development,  it  becomes  important  for  the  curriculum  planner  to 
determine  what  is  meant  by  "literacy"  and  what  problems  and 
issues  are  causing  this  software  crisis.  Armed  with  this 
information  the  planner  can  develop  a  course  for  senior  leaders 
who  in  turn  will  be  able  to  avoid  some  of  the  documented 
pitfalls.  The  next  two  chapters  then,  highlight  common  problems 
and  issues  of  the  software  crisis. 


Chapter  ThrN 


THE  LIFE  CYCLE  ISSUES 


FSAHEWORK  FOg  PRESENTATION 

Host  of  ths  rsports  surveyed  for  this  paper  prvMotcd 
different  problem  area  •  in  soft  wart  dsvtlopwnt.  There  dot*  not 
appsar  to  ba  ona  systemic  proto laa  (unlass  ona  concluda*  industry 
suffars  fro*  a  lack  of  a  " trua“  software  tnginaar  mg  disc  tpl  ina)  . 
Tha  only  cotton  theme  among  authors  is  thara  ara  savaral 
contributing  parts  to  this  software  crisis.  In  ordar  to  show 
them,  this  chap tar  usas  a  1 i f a  cycla  modal  to  provida  a  logical 
f raaawork .  Thara  ara  many  dascnptions  of  aach  stap  of  tha  1 1  f a 
cycla.  Ona  modal  labals  tha  stapst  raquirasants, 
pacifications,  dasign,  prograating,  tasting,  intagration 
tasting,  daployaant,  and  aaintananca.  Tha  DODs  modal  labals  tna 
phasas  asi  conctpt,  faaaibility  study,  raquiraaants  dafinition, 
dasign,  coding  and  chackout,  tasting,  intagration,  oparational 
tast  and  avaluation,  and  daployaant  aaintananca  <4i 170-179). 

Ha war  mods  Is  hava  appaarad  to  accompany  tha  mat hods  of  structurad 
analysis,  dasign  and  programming.  Stnca  no  standard  sat  of 
labals  nor  modal  exists,  it  is  nacassary  to  discuss  problams 
about  tha  softwara  lifa  cycla  in  tarms  of  a  highar  laval  of 
abstraction.  Using  an  adaptation  of  anothar  modal,  it  should  ba 
safa  to  classify  all  staps  of  tha  lifa  cycla  in  tarsi*  of  thraa 
catagoriasi  conctpt  davalopmant ,  systam  davalopstant ,  and  finally, 
systam  daployaant  <34i3>. 


CONCEPT  PEVELOPHENT 

This  phasa  of  tha  softwara  lifa  cycla  bagins  with  tha  usar  s 
concaptual ization  of  an  automatad  naad ,  ba  it  an  accounting  and 
financa  systam  or  a  fir*  control  proctssor  on  an  tdvtncad 
fightar.  Tha  usar ,  of tan  with  tha  ho  1 p  of  a  computar  systass 
analyst,  statas  tha  raquiramant  and  wr i tas  tha  spac i f icat ions. 

Tha  "sptcs"  Is tar  bacoma  tha  critaria  for  judging  an  accaptable 
product.  Finally,  tha  phasa  and*  with  soma  typa  of  broad  or 
g an ara 1  dasign. 

A  common  problam  in  this  phasa  is  mccaplctc  raquiramants 
definitions  (li303).  Savaral  reasons  arai  tha  usar  doom  not  mow 
what  is  desired)  tha  usar  changes  tha  requirements)  tha  usar  doe* 
not  know  how  to  express  tha  raquiramant)  tha  analyst  incorrectly 
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interprets  the  requirement;  and,  all  parties  are  under  pressure 
to  proceed  into  the  systee  development  phase  (31iie>.  The  latter 
is  a  common  problem  even  though  many  stress  the  Importance  of 
having  adequate  time  to  define  and  design.  The  pressure  starts 
because  the  concept  development  phase  shows  the  least  visible 
measure  of  personnel  productivity.  How  can  one  measure  thinking 
as  opposed  to  1 ines-of-code  or  programs  constructed?  Hence, 
there  is  strong  pressure  to  move  on  to  an  area  that  begins  to 
show  visible  results  rather  than  devoting  the  needed  time  to 
requirement  definition.  For  example,  in  a  review  of  84 
contracts,  23  percent  had  unclear  statements  of  work  or 
incomplete  definitions  of  requirements.  Of  the  products 
delivered,  the  majority  were  unsatisf actory ,  delayed,  incurred 
cost  overruns  or  had  a  combination  of  the  three  < 28 « 7-3 > . 


Even  with  requirements  defined  completely,  there  often  is 
another  problems  errors  in  the  requirements  documentation  and 
design  step  (lt241).  In  fact,  the  larger  the  product,  the  more 
often  the  number  of  design  errors  exceeds  the  number  of  coding 
errors  (Is  242).  One  estimate  was  83  percent  of  the  bugs  were  in 
the  requirements  documentation  and  design  steps.  These  bugs  are 
expensive  to  correct  <4s37-38>. 


Since  r 
is  no  wonde 
cost  and  sc 
this  phase 
From  the  re 
approaches 
permits  the 
length,  and 
"manageable 
<29*  3-10) . 


equirements  are  often  incomplete  or  contain  errors,  it 
r  it  is  nearly  impossible  to  predict  the  complexity, 
hedule  of  any  project.  A  method  to  reduce  problems  in 
is  to  conduct  an  open  review  of  a  preliminary  design, 
view,  designers  obtain  agreement  this  rough  sketch 
the  stated  requirement.  Having  an  approved  design 
developers  to  better  estimate  project  complexity, 
cost.  Hence,  until  preliminary  design,-  there  is  no 
level  of  software  predictability  and  control" 


One  study  reported  most  Air  Force  software  acquisitions  are 
fixed  before  this  design  review.  This  means  the  statement  of 
work,  used  in  the  acquisition,  may  not  match  the  desired  require¬ 
ments.  If  they  do  not,  then  the  budget  process  will  use 
erroneous  cost  estimates  based  on  invalid  requirements  and 
falsely  limit  the  fixed  price  contracts.  The  ripple  effect  ends 
with  "best  and  final  offers,"  based  on  improper  requirements  and 
poor  cost  estimates,  guaranteeing  built-in  cost  and  schedule 
overruns  <29»3-ll>. 

Having  a  design  and  conducting  a  review  reduces  the  risk  but 
do  not  eliminate  all  problems  with  the  requirements  and 
spec l f icat ions  steps.  Embedded  software  specifications  use 
hIL-STD  483/49#  the  same  as  hardware  procurements.  The 
difference  is  “form,  fit,  function,  materials,  components  and 
previous  designs  may  be  described  in  considerable  detail"  for  the 


hardware,  whereas  the  software  specifications  "concentrate  almost 
exclusively  on  describing  performance  and  function.  .  .  .  The 
control  that  an  Air  Force  procurring  or  developing  agency  has 
over  cost,  schedule,  and  maintainability  is  ultimately  limited 
because  of  such  a  general  specification"  (42i 14) .  Furthermore, 
given  that  the  design,  by  definition,  is  preliminary,  or  at  the 
least  conceptual  in  nature,  then  the  development  will  be  a 
function  of  the  designer's  "logic  and  ideas".  This  places  the 
“cost,  maintainability,  and  schedule  at  the  mercy  of  the 
experience,  efficiency,  and  effectiveness  of  the  developer's 
design  team"  <42il4). 


SYSTEM  DEVELOPMENT 

This  life  cycle  phase  includes  the  detailed  design, 
programming,  integration,  testing  (component  testing,  integrated 
systems  testing  and  operational  testing),  and  evaluation.  From 
the  viewpoint  of  the  system  developer,  in-house  or  contract,  the 
software  development  issues  are  the  same.  From  the  Air  Force 
perspective,  there  are  additional  risks  in  software  development 
contracting. 

Development  Issues  In  Seneral 

Robertson  (40:74-94)  categorized  the  issues  affecting 
software  development  into  four  categories.  They  are:  physical 
environment,  structural  environment  (staffing,  awards  and 
incentives,  suggestion  programs,  flextime),  development  and 
maintenance  tools  (hardware  considerations,  software  tools),  and 
intellectual  skills.  These  four  categories  can  positively  or 
negatively  affect  productivity.  A  discussion  of  the  first  three 
follows  while  intellectual  skills  will  be  deferred  until  the  next 
chapter's  discussion  on  training. 

The  physical  environment  describes  the  building,  office 
setting,  and  the  office  equipment.  Terminals  designed  to  reduce 
glare  and  eyestrain,  chairs  designed  to  reduce  backache,  desks 
equipped  to  handle  several  unfolded  computer  printouts  and 
bookcases  to  store  documen ta t i on  are  examples  of  office  equipment 
necessary  for  motivating  workers  and  increasing  productivity. 

The  numbers,  types  and  locations  of  the  terminals  can  be  a 
consideration.  Areas  to  help  exchange  ideas,  like  conference 
rooms,  and  quiet  office  space  to  further  concentration  are 
important  too.  While  there  are  few  documented  studies  to  confirm 
these  ideas,  IBM  estimated  their  we  1 1 -des i gned  facility  at  Santa 
Teresa  generated  an  11  percent  improvement  in  programmer 
productivity  <40i76>.  The  Bold  Stroke  Briefing  Team  claims  if 
the  environment  is  poor  it  could  decrease  productivity  20 
percentj  if  good,  increase  it  20  percent  <33: Tab  3).  The 


physical  environment  is  important  bscauss  programming  is  such  a 
mentally  intensive  activity. 


Staffing,  one  of  the  structural  environment  aspects,  equates 
to  management  learning  how  to  motivate  programmers t  especially  if 
management  wants  an  increase  in  productivity.  Some  programmers 
are  ten  times  more  productive  than  others  (40i77>.  With  an 
increasing  backlog  of  programming  requests  and  increasing 
shortages  of  computer  personnel ,  there  is  a  real  need  for 
increased  productivity.  The  USAF  Scientific  Advisory  Board 
estimates  the  annual  increase  in  staffing  and  productivity  will 
be  4  percent  each  but  the  demand  will  still  outpace  the  growth  by 
12  percent.  This  means  an  ever  widening  gap  between  supply  and 
demand  <2?i3-27|  24« 136-138).  One  opinion  is  productivity  must 
increase  by  a  factor  of  100  in  the  next  10  years  if  development 
is  to  match  need  <4t21). 

Development  and  maintenance  tools  refer  to  the  computer 
hardware  and  software  support  in  doing  development.  Productivity 
suffers  from  poor  hardware  tools  when  terminal  response  times  are 
long,  program  execution  speeds  are  slow, 'main  storage  is  small  or 
constraining,  and  job  turnaround  time  is  long  (40t83-85>.  If  the 
organization  lacks  software  tools  to  do  prototyping,  project 
managing,  budgeting,  auto  documenting,  interactive  debugging, 
auto  coding  or  database  maintaining,  then  productivity  suffers 
again. 

Contracting  Issues 


"In  a  recent  software  contract  the  Air  Force  estimated  that 
the  cost  would  be  41.5  million.  The  contractors  low  bid  was 
S400  thousand.  But  the  final  cost.  .  .  turned  out  to  be  S3. 7 

million"  <15i2>.  While  this  gets  attention,  it  is  only 
symptomatic.  The  General  Accounting  Office  surveyed  163  software 
firms  and  113  Federal  project  officers  experienced  in  software 
development  contracts  <21i — ).  They  concluded  their  report  with 
five  important  causes  to  the  contract  problems. 

The  first  was  a  lack  of  central  guidance  on  contracting. 

This  can  lead  to  using  inappropr i ate  contracts,  e.g.,  fixed  price 
and  unspecified  deliverables.  A  second  cause  is  top  management 
not  committing  enough  qualified  people  to  the  contract.  Often, 
the  government's  and  the  contractor's  staffing  remains  below 
sufficient  levels  for  the  entire  life  cycle  (1:305).  Spending 
limitations  can  cause  staffing  problems  too.  The  author  recalls 
one  project  staffed  incrementally  because  of  fiscal  constraints. 

A  third  cause,  cited  before,  is  committing  to  a  project  before 
specifications  and  requirements  are  completed.  A  fourth  cause  is 
poor  contract  management.  Lastly,  because  of  incomplete, 
inadequate  requirements  and  specifications,  the  government  may 


not  adequately  tost  tho  final  product  <21 i 27-28) 


Another  proto  1mm  occurs  with  embedded  systems  whon  tho  size  of 
tho  dovolopoont  is  largo.  It  is  not  atypical  for  a  dovolopnont 
to  span  throo  yoars.  In  this  instance,  tho  contract  is  ofton  lot 
boforo  tho  hardware  design  occurs.  Hones,  tho  software  oust  bo 
developed  without  specifying  tho  interface  requirements  <31ilB> 
or  tho  hardware  delivered  does  not  do  what  the  software  designers 
expected.  In  either  case  integration  is  difficult  and 
engineering  change  proposals  inevitable  (lt30S).  Another  likely 
possibility  is  the  user's  needs  will  change  during  a  long  span 
ties,  again,  oaking  changes  necessary. 

Lastly,  though  attributed  to  probleee  of  oanageeent, 
discussed  in  the  next  chapter,  the  following  quote  appears  here 
to  cooplete  this  section  on  contract  issuest 

Seventy-five  percent  of  the  84  software  contracts 
examined  had  at  least  one  type  of  management  problem. 
Software  contracts  were  written  that  did  not  contain 
clear  and  complete  statements  of  workp  rights  of 
technical  data  clausesi  adequate  documentation  and 
software  standards!  and  comprehensive  test  and 
acceptance  criteria.  Guidance  was  not  available  to 
clarify  and  provide  an  overview  of  existing  DOD  and 
non-DOD  publications  on  software  quality  assurance 
programs  and  standards.  There  were  no  reviews  of 
purchase  requests  for  software  contracts  by  personnel 
familiar  with  data  processing,  procurement  and  quality 
assurance.  Contracting  officer  technical 
representati ves  (COTRs)  for  software  contracted  did  not 
have  adequate  training  on  how  and  when  to  recommend  the 
use  of  contract  clauses  to  protect  the  interests  of  the 
DOD.  As  a  result  of  these  problems,  some  software 
contracts  cost  more  than  planned,  were  not  completed  on 
time  and/or  were  not  satisfactory  when  delivered  or 
were  never  delivered  <28«7-2>. 


SYSTEM  DEPLOYMENT 


This  phase  assumes  all  testing  is  complete  and  the  system 
becomes  fully  operational.  Maintenance  is  the  key  function  in 
this  phase.  However,  software  "maintenance"  may  be  a  misnomer, 
i.e. ,  there  are  no  parts  to  wear  out  or  to  replace.  True,  some 
logic  errors  exist,  but  these  account  for  only  18  percent  of  the 
total  maintenance  effort  <37i3).  The  bulk  of  maintenance  is 
correcting  design  flukes  and  responding  to  changes  in 
requirements.  According  to  the  Scientific  Advisory  Board  Study, 
maintenance  is  fixing  the  immediate  errors  and  achieving  full 


capability  because  of  inadequate  design  or  changes  to  the 
hardware.  These  efforts  are  really  "mini -developments"  rather 
than  software  "maintenance"  (29:3-30  -  3-31). 


Besides  inadequate  design  driving  maintenance  activities 
several  other  issues  are  common.  Long  development  times  can  lead 
to  new  systems  fielded  on  obsolete  hardware  (40:52).  Missions 
change.  For  example,  in  the  Falkland  hostility,  navigational 
systems  had  to  be  changed  to  fly  in  the  southern  hemisphere 
(24:6).  Lastly,  problems  arise  when  the  software  development 
organization  completes  its'  task  and  transfers  the  product  to  the 
support  organization.  Often  the  support  organization  has  had  no 
prior  involvement  with  the  system. 

Previous  paragraphs  have  cited  development  costs  and  schedule 
overruns.  It  is  interesting  to  note  the  significance  of  the 
maintenance  issue.  One  estimate  is  development  costs  *30  per 
line  of  code  whereas  maintenance  costs  *4000  per  line  of  code. 

In  1990,  maintenance  will  be  70  to  80  percent  of  the  software 
budget  <38i52-53).  It  is  also  40  to  95  percent  of  the  personnel 
effort  (37:3).  Supporting  this  last  statistic,  GAO  noted  in  a 
review  of  15  federal  computer  sites,  software  maintenance 
accounted  for  an  annual  expenditure  of  *38  million.  Of  this 
amount  71  percent  was  for  salaries.  They  concluded  the 
government  spends  *1.3  billion  annually  (22: l).  Martin  provides 
a  more  1 iberal  estimate:  the  DOD  spends  *2  billion  per  year  and 
expects  to  pay  *16  billion  by  the  end  of  the  1980s  (4:7). 

In  short,  the  inherent  flexibility  of  software  to  meet  new 
mission  needs  dictates  maintenance.  However,  maintenance  is  very 
costly,  far  exceeding  the  cost  of  development.  To  reduce  costs 
one  must:  design  for  maintenance  while  in  the  concept  development 
phase:  and,  employ  automated  maintenance  tools  wherever  possible. 
Unfortunately ,  neither  is  simple  as  discussed  in  the  previous  two 
phases. 


LIFE  CYCLE  SUMMARY 


This  chapter  has  highlight 
in  each  phase  of  the  life  eye  1 
points  are:  the  critical  phase 
incomplete  and  erroneous 
later  problems;  and,  the 
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d  many  of 
.  However 
is  concept 
•quirements  art 
'ployment  phase 


the  problems  occurring 
,  the  two  most  important 
development  because 
the  biggest  causes  of 
is  the  cost  1  lest. 
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Chapter  Four 


THE  MANAGEMENT  ISSUES 

The  topics  in  this  chapter  are  distinct  and  do  not  lend  them¬ 
selves  to  a  logical  framework  such  as  in  the  previous  chapter. 
Their  only  common  link  is  they  relate  to  management's  ability  to 
influence  their  impact.  The  topics  arei  management's  technical 
competency,  manpower  shortages,  personnel  management,  produc¬ 
tivity,  training,  and  project  management  oversight. 

Management's  Technical  Competency 

The  USAF  Scientific  Advisory  Board's  recommendations,  were  in 
large  part,  the  impetus  for  Project  Bold  Stroke,  concluded  with 
the  basic  "belief  that  the  true  essence  of  the  solution  is 
effective,  enlightened  management"  <29i4-9).  Several  reports 
echo  this  sentiment: 

Being  knowledgeable  about  technology  is  essential  if 
management  is  to  avoid  giving  up  control  of  major  areas 
of  their  job.  .  .  .  Having  management  that  is  not 
technically  oriented  can  be  a  critical  factor  in  the 
failure  of  any  technological  system.  .  .  .  They  do  not 
have  to  be  experts,  but  they  need  to  understand  it 
because  they  must  be  the  ones  to  ask  the  penetrating 
'what  if'  questions.  ...  In  fact,  before  making  any 
technical  decision,  the  first  step  should  be  training 
top  management  to  understand  it  (8:103). 

.  .  .  new  software  technologies  create  some  serious 

challenges.  Air  Force  managers  must  be  able  to 
evaluate  new  systems  and  insure  requirements  are 
satisfied  (41:10). 

Computer  technology  is  complex  and  changing  so  rapidly 
that  skilled  technicians  at  senior  levels  (GS-13  and 
above)  are  not  a  luxury  but  a  necessity  (40:14). 

A  major  campaign  should  be  conducted  to  improve  the 
computer  literacy  of  Air  Force  personnel  (28:21). 

Technological  and  scientific  advances  do  not  require 
all  Air  Force  officers  to  be  engineers  or  scientists, 
but  all  officers  will  need  to  be  technically  literate 
( 36: 23) . 
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From  1972  to  1984,  Air  Force  end-strength  -fell  20  percent. 

An  increasing  use  of  automation  helped  to  offset  this  manpower 
decline.  Yet,  ADP  spaces  increased  only  12  percent  in  the  same 
period  (28:5).  This  meant  an  increasing  demand  for  a  slowly 
increasing  pool  of  resources.  More  important  is  the  concern  for 
competition  between  the  DOD  and  industry  for  this  resource.  "The 
national  shortfall  of  some  80,000  civilian  and  military  software 
professionals  is  expected  to  swell  to  1,000,000  by  1990"  (5:46). 
Also,  there  is  evidence  of  a  growing  attrition  rate  among  lower 
ranking  enlisted  within  the  ADP  field  (29:3-26).  "Good  military 
programmers  are  lured  away  in  droves  by  industry  and  mesmerizing 
salaries"  (13:12).  The  implications  are  clear:  the  military  and 
industry  demand  for  ADP  professionals  will  increase;  competition 
will  be  strong;  and,  the  DOD  will  have  an  added  constraint  of 
facing  stagnant  or  decreasing  manpower  authorizations  in  the  face 
of  austere  budgets  (41:6;  5:48:  29:3-53).  If  the  competition  is 
keen .and  resources  are  dwindling,  effective,  efficient  management 
of  personnel  is  obligatory. 

Personnel  Management 

"Education,  training,  assignment,  progression,  and  retention 
of  both  military  and  civilian  personnel  in  the  computer  area  are 
recognized  as  significant  problems  at  all  levels  in  the  Air 
Force"  (30:16).  It  is  interesting  to  note  this  quotation  is  from 
a  report  published  in  1970.  Ten  years  later,  a  student  officer 
published  a  review  of  career  irritants  adversely  affecting 
science  and  engineering  officers  (including  the  ADP'  field).  He 
raised  several  issues.  Among  them: 

1.  The  utility  of  training  is  particularly  important  in 
an  officer's  career.  After  the  sixth  year,  officers  do  not  feel 
the  Air  Force  is  providing  this  utilization  (35:10). 

2.  Most  feel  rated  as  technicians  by  their  supervisors 
but  must  compete  in  the  "whole-person  concept"  for  promotion 
boards.  A  civilian  scientist  or  engineer  is  always  evaluated 
within  the  organization  based  on  job  performance  (35:22). 


3.  The  1974  Air  Force  Career  Motivation  Conference 
recommended  a  dual  track  career  ladder  for  science  and  engi¬ 
neering  officers.  The  idea  was  to  let  the  officer  remain  a 
technician  until  retirement.  The  idea  was  rejected  for  two 
reasons:  civilians  could  be  used  and  there  were  not  enough  field 
grade  slots  to  permit  the  concept  (35:25). 


4.  The  science  end  engineering  officer  "at  the  five 
year  point  in  his  career  must  carefully  weigh  the  prudence  of 
investing  six  more  years  of  his  life  for  a  50  percent  chance  of 
making  0-4  and  allowing  him  to  continue  a  full  career  in  the  Air 
Force"  <35«28). 

Though  striking  the  institutional  notion  of  generalist  versus 
specialist,  the  last  two  points  surface  again  in  the  USAF 
Scientific  Advisory  Board's  report* 

The  Air  Force  must  provide  adequate  career  paths  for 
both  military  and  civilian  technical  staff  personnel  to 
ensure  that  the  most  highly  qualified  have  the  headroom 
necessary  to  advance  in  the  career  field.  Currently, 
qualified  engineers  and  computer  science  personnel  must 
either  leave  the  service  or  move  laterally  into 
management  career  fields  in  order  to  advance  (29:3-54). 

Productivity 

With  growing  requirements  and  a  shortage  of  people,  "doing 
more  with  less"  will  be  the  norm.  Since  an  increasing  require¬ 
ments  backlog  is  unacceptable,  it  becomes  important  to  focus  on 
producti vi ty .  A  1984  "Report  on  Data  Systems  Management  and 
Manpower  Impacts"  estimates  the  Air  Force  needs  a  productivity 
"increase  of  19*/,  compounded  annually,"  to  eliminate  the  ADP 
requirements  backlog  by  1990  (28*11-7).  However,  there  are 
several  management  impediments  to  increasing  productivity.  The 
following  are  seven  barriers: 


Improving  productivity  is  often  a  slow  process. 

Unfor tunately  there  is  strong  pressure  to  produce  quick 
results.  Assignment  rotation  may  even  be  a 
contributing  factor.  Not  'getting  around'  is  another 
barrier  to  increasing  productivity  and  motivating 
subordinates.  Managers  unwillingness  to  experiment 
with  new  ideas  hurts  initiative.  Regulations  and 
policies  created  'on  high'  may  not  address  the  real 
problems.  Lack  of  incentives  and  poor  management 
training  are  two  more  hurdles.  Finally,  the  'never 
enough  time  to  do  it  right  but  always  enough  time  to  do 
it  over'  is  a  common  problem  in  all  disciplines 
(40*96-98) . 


Recall  -from  the  previous  chapter  four  categories  of  issues 
affecting  software  development.  One  of  those  issues,  intel¬ 
lectual  skills,  dealt  soley  with  training.  Robertson  made 
several  points.  First,  develop  a  good  training  program.  Second, 
ensure  workers  and  managers  attend.  Third,  realize  training 
meets  the  intrinsic  growth  needs  of  professionals,  keeps  them 
current  with  technology,  increases  productivity,  and  serves  as  a 
reward.  Finally,  understand  a  short  term  decrease  in  produc¬ 
tivity  will  be  offset  by  a  long  term  increase  in  productivity 
<40! 92-93) . 

While  the  DOD  has  several  training  facilities  and  programs, 
there  has  been  some  criticism.  One  surveyed  report,  by  Hedges, 
dealt  solely  with  this  issue.  His  view  was  the  DOD  trains  only 
for  the  programming  step  (23:22-23)  but  there  are  five  other 
areas  of  computer  science:  design,  acquisition,  implementation, 
operations  and  maintenance  (23:38-41).  Furthermore,  he  claims 
problems  in  software  cannot  "always  be  placed  at  the  doorstep  of 
changing  requirements ,  lengthy  approval  times  for  acquisition, 
and  so  on."  "Austere  training  budgets"  fail  to  keep  software 
people  "smart"  (23:26).  With  the  continual  flux  in  methods, 
keeping  abreast  of  new  techniques  is  paramount.  "Disciplines 
like  systems  engineering,  data  base  engineering,  and  computer 
networking  offer  tomorrow's  challenges.  Aggressive  training  in 
all  of  these  areas  should  be  a  high  priority"  (41s 7). 

Project  Management  Oversight 

Oversight  is  important  because  cost  overruns  can  impact 
budgets  and  cause  funds  to  be  unavailable  for  other  projects. 
Also,  delays  in  delivery  can  hu.' t  operational  readiness.  Though 
important,  there  are  difficulties  in  managing  software  develop¬ 
ment  projects.  One  problem  is  finding  a  reliable  method  for 
estimating  costs.  A  popular  method,  by  Boehm,  is  successful  only 
68  percent  of  the  time  in  estimating  costs  within  20  percent  of 
the  actual  expenditure  (40:109).  Unf or tunately ,  it  appears 
Boehm's  method  is  the  best  predictor  at  the  moment.  Scheduling 
is  another  problem,  i.e  many  managers  fail  to  keep  up  with 
cumbersome  PERT  charts  or  do  not  have  access  to  automated  project 
management  tools.  It  is  not  only  important  to  estimate  cost  but 
to  estimate  schedules  and  then  manage  to  cost  and  schedule 
(29:2-3) . 


A  problem  with  embedded  software  in  large  weapon  systems  is 
it  is  not  reported  as  a  line  item  in  the  status  reports  and 
becomes  overlooked  by  management  (28:23).  However,  the  software 
component  may  be  the  essential  element  deserving  senior  level 
attention.  For  example: 


The  X-29  supersonic  aircraft  with  the  forward  swept 
wing  design  illustrates  the  critical  nature  of  software 
to  system  performance.  Totally  dependent  on  software 
controlled  electronic  commands,  the  aircraft  requires 
instant  response  and  feedback  at  subsonic  speeds  to 
compensate  for  its  instability  at  those  speeds.  (e.g.. 

Any  pitch  divergence  can  rapidly  double  in  tenths  of 
seconds).  Rapid  and  accurate  data  feedback  is  required 
to  insure  balance  and  reliable  performance.  In  brief, 
while  the  software  component  is  not  necessarily  the 
largest  element  of  the  system,  it  is  vital  to  the 
functioning  of  the  aircraft  (24:3). 

Sometimes  the  opposite  occurs  and  status  reports  are  too 
detailed,  becoming  useless  and  costly. 

Another  study  suggested  high  level  management  has  little  time 
for  the  subject  or  is  software  illiterate  (29:3-18),  harking  back 
to  the  issue  of  technical  competency.  "Every  software  oversight 
manager  should  be  trained  in  both  computer  software/ hardware 
engineering  design  concepts  and  practices  and  oversight  manage¬ 
ment  techniques"  (29:3-23).  Whether  it  is  little  time  or 
software  illiteracy,  lack  of  oversight  can  result  in  a  reduction 
of  mission  capability,  cost  overruns  and  schedule  delays.  "For 
example,  the  Air  Force  and  the  Navy  had  to  postpone  making  some 
much-coveted  changes  for  the  better  in  their  respective  F-16  and 
F/A-18  fighters  when  the  software  that  they  had  counted  on  for 
such  changes  -  as  in  radars  -  was  not  ready  on  schedule"  (5:47). 

Security 


In  conducting  this  research,  it  was  disconcerting  to  note  few 
articles  exist  on  the  software  crisis  and  security.  The  author 
believes  the  following  merits  reflection: 

1.  As  the  Air  Force  increases  its'  emphasis  on 
contracting  for  software  development  (28:7-4),  more  and  more 
systems  will  be  developed  "out-of -house. "  While  "in-house" 
development  does  not  guarantee  uncompromised  security,  it  can 
limit  access  to  software  and  documentation.  At  the  least, 
administration,  phone  calls,  and  mailings  between  the  requirement 
activity  and  the  contractor  complicates  security  procedures. 

2.  The  software  development  process  may  involve 
computer  networking.  One  should  note  networks  and  security  have 
conflicting  goals  (41:10). 
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3.  Usual  security  thinking  dwells  on  preventing 
compromises.  However,  there  are  at  least  two  other  concerns: 
sabotage  by  disgruntled  workers  and  damage  to  data  by  poorly 
written  software.  One  article  (16: — )  referred  to  the  latter  as 
"unsafe"  or  "hazardous"  software. 

4.  Who  will  check  commercial,  "off-the-shelf"  software 
for  reliability  and  security  <44i — )? 


MANAGEMENT  ISSUES  SUMHARY 

This  chapter  has  highlighted  seven  broad  areas  of  management 
issues.  All  of  these  issues  concern  human  resource  and  project 
management.  While  the  problems  vary  in  nature,  their  complexity 
is  attested  to  by  the  fact  some  of  the  issues  are  nearly  two 
decades  old.  The  need  for  a  "bold  stroke"  is  evident. 


WiW 


Chapter  Five 


PROPOSED  COURSE 

This  chapter  begins  with  the  groundwork  of  whom  the  students 
will  be,  the  focus  of  the  course,  and  what  is  meant  by  "computer 
literacy."  The  chapter  concludes  with  the  suggested  course 
length  and  topics  supporting  Task  II-A  of  Project  Bold  Stroke. 

The  intent  is  to  provide  a  course  for  Air  Force  senior  leadership 
to  address  the  issues  and  avoid  the  pitfalls  presented  in  the 
previous  two  chapters. 


PREFACE  TO  THE  PROPOSAL 


Analysis  of  the  Audience 

Task  II-A  has  not  been  modified  as  of  this  writing.  This 
means  students  in  the  short  course  will  be  general  officers  and 
equivalent  grade  civilians  who  have  responsibility  for  software 
development.  (If  they  have  responsibility  for  software  develop¬ 
ment,  they  may  be  familiar  with  software  issues.)  Task  II-A  also 
specifies  newly  selected  brigadier  generals  attend.  Likely,  most 
personnel  at  this  level  have  varied  background  with  a  strong  dose 
of  command  and  operations  experience.  In  other  words,  special¬ 
ization  in  software  development,  a  support  field,  is  unlikely  for 
most  students.  The  course  should  aim  at  students  with  little 
knowledge  of  the  course  material. 

The  "ADP"  Versus  "Embedded"  Focus 


Initially,  Project  Bold  Stroke  was  about  embedded  software 
systems.  During  the  team's  investigation  it  became  clear  the 
problems  incurred  in  A DP  and  embedded  systems  were  similar 
(43s — ).  However,  there  appears  to  be  an  attempt  to  stress  one 
facet  over  the  other.  A  senior  official  has  emphasized  Project 
Bold  Stroke  should  focus  attention  on  software  engineering  in  the 
operational  and  acquisition  worlds  rather  than  being  a  genera¬ 
lized  "information  systems"  education  (19: — ).  This  is  an 
accepted  euphemism  for  ADP  vice  embedded  software.  Several 
months  later  a  senior  official  expressed  the  same  view  and 
criticized  the  Project  as  drifting  towards  "AFCC  type  information 
systems";  Bold  Stroke  should  focus  on  embedded  weapon  system 
software  managed  by  AFSC  and  should  be  about  the  acquisition  and 
management  of  mission  critical  software  (20: — ).  Another  senior 
official  agreed  Project  Bold  Stroke  was  for  weapon  systems  (10:8) 
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but  wanted  to  create  a  project  similar  to  Bold  Stroke  for 
increasing  awareness  of  ADP  type  systems  <18t — ).  It  is  hoped 
that  personal  viewpoints  will  not  override  the  Bold  Stroke  team's 
findings!  the  problems  are  serious,  affecting  both  ADPE  and 
mission  critical  systems  (25i — 5  43i — >.  Recall  from  Chapter 
One,  this  paper  assumes  there  are  few  differences  in  the  problems 
affecting  botn  types  of  systems  i.e.,  there  are  many  similarities 
in  managing  ADP  and  embedded  software. 

The  Goal  of  Computer  Literacy 

"Because  each  profession  or  discipline  has  different  specific 
needs  that  can  be  met  by  computers,  it  is  impossible  to  develop  a 
generic  computer  literacy  course”  <3i74>.  Bold  Stroke  Task  II-A 
targets  senior  leaders  having  software  management  responsi¬ 
bilities  as  the  “profession  or  discipline”  needing  the  short 
course  in  software  literacy.  For  them,  a  Rand  study  provides  a 
good  definition  of  computer  literacy: 

Computer  literate  is  a  loosely  defined  term  implying  an 
awareness  on  some  level  of  understanding  about  aspects 
of  computer  affairs.  It  is  usually  applied  to 
individuals  who  are  not  formally  trained  in  a  computer 
discipline  but  who  need  an  overview,  often  in  depth,  of 
the  field  for  some  purpose.  From  the  viewpoint  of  the 
professional  practi tioner ,  'computer  literate'  would 
describe  the  lay  person  who  can  speak  knowledgeably 
about  computers  in  general.  .  .  .  The  term  emphasizes 

the  insights  and  perspectives  relevant  to  overseeing 
computer — related  project  development  (27:2). 


PROPOSED  COURSE  OF  INSTRUCTION 

Course  Length 

A  "minimum  course  in  computer  literacy,"  teaching  only 
microcomputer  fundamentals,  "would  require  about  sixteen  hours  of 
carefully  planned  instruction"  (3:74).  This  falls  far  short  of 
teaching  the  issues  presented  in  the  previous  two  chapters.  Task 
II-A  suggested  a  course  of  three  to  five  days;  the  author 
recommends  five  days.  While  allowing  adequate  time  for  instruc¬ 
tion  on  the  complex  issues,  this  length  has  an  added  benefit:  if 
the  Air  Force  shows  its"  concern  by  encouraging  senior  leaders  to 
devote  valuable  time  to  these  subjects,  then  it  lends  more 
credibility  to  the  criticality  of  software  in  Air  Force  systems. 


The  author  rtcow— nds  the  first  day  ot  instruction  s rv»  as  a 
Motivator  and  a  "break-in"  period  lor  the  students  because 
coeputer  technology  can  cause  apprehension  and  hostility  among 
the  uninitiated  and  senior  stall  <81 1S3;  Ili34|  14t43>. 

A  new  jargon  has  esmrged  to  describe  people  s  negative 
reactions  that  make  it  dillicult  lor  them  to  use  the 
technology  ellectively.  Such  terms  as  computerphobia, 
cyberphobia,  technophobia,'  and  '  technostress  charac¬ 
terize  the  resistance  to  change  in  the  work  place  and 
emphasize  how  critical  it  is  to  understand  and  plan  lor 
the  human  perspective  when  installing  new  technology 
<9i 12) . 

This  "break-in"  and  introductory  phase  on  day  one,  should  use 
personal  computers  (PC) .  They  are  small,  individual  computers: 
easily  used  and  demonstrated.  Contrast  this  vehicle  ot  instruc¬ 
tion  to  a  tour  ol  a  large  (overwhelming)  ADP  lacility  or  display¬ 
ing  a  ruggedized,  embedded  (mysterious)  system.  Furthermore,  the 
instructor  can  open  the  PC  to  show  the  internal  hardware, 
destroying  the  notion  ol  computers  as  “black  boxes".  PCs  are 
popular  conversation  items  and  widely  available  commercially. 

This  can  be  a  motivation  to  learn  (3:3).  Instruction  should 
cover  PC  hardware  and  soltware.  In  doing  so,  the  instructor  must 
avoid  one  common  error. 

.  .  .  in  computer  literacy  classes  is  the  tendency  to 

teach  about  a  particular  computer  as  il  knowledge  ol 
its  special  features  were  important  to  computer 
literacy.  .  .  .  Computer  literacy  instructors  must 

make  every  effort  to  stress  the  general  principles,  the 
translerable  character ist ics ,  and  the  universality  ol 
the  concepts  they  teach.  This  can  be  done  even  while 
illustrating  the  particular  implementation  ol  a 
specific  machine.  .  .  .  Moreover ,  a  general  discussion 

ol  the  principal  leatures  ol  small  computers  oilers  an 
accessible  and  relatively  simple  approach  to  the 
general  lunctions  ot  all  computers,  however  actually 
implemented  in  hardware  (3:74-75). 

Alter  the  introductory  phase,  the  author  recommends  day  two 
and  three  cover  chapters  two  through  tour  of  this  paper.  At  the 
least,  these  chapters  cover  the  design,  acquisition,  implemen¬ 
tation,  programming,  operation  and  maintenance  subjects 
recommended  by  Hedges  in  his  study  of  computer  science  training 
within  the  DOD  (23:37). 


Day  th re#  should  and  with  at  least  on#  c«u  study  on  th* 
•oftaart  impact  to  raadinass.  For  example,  iaprovsants  to  th# 
F-lfc  Mart  postponed  bacausc  of  delays  in  tof twara  dalivary 
<9i47).  Th*  css*  study  Mill  rainforc*  days  two  and  thr»*  while 
r Minding  th*  stud*nts  of  th*  criticality  of  software. 

It  now  becoaas  appropriate,  on  day  four,  to  present 
solutions.  Th*  author  reiterates  only  highlights  can  be  taught. 
Sine*  i n-d*p th  presentations  of  possible  solutions  is  not 
feasible,  recommended  readings  or  a  des^  reference  set  with 
checklists  should  supp 1  seen t  the  lectures.  The  goal  is  to  arm 
the  students  with  th*  "right  questions"  to  pose  to  their  staffs 
when  they  have  software  oversight  responsibilities.  Examples  of 
topics  arei  incremental  or  evolutionary  acquisition]  measuring 
progr ameer  productivity!  negotiating  contracts!  motivating 
personnel]  predicting  costs  and  controlling  schedules!  etc. 

Finally,  the  course  should  conclude  with  a  description  of  the 
organization*  involved  in  embedded  and  A DP  information  systems 
within  th#  Air  Force,  th#  DOD  and  th#  Federal  gover nment .  Th# 
key  is  to  give  more  than  just  wiring  diagrams.  The  lecturer 
should  identify  who  is  the  'expert  help"  and  where  it  is  avail¬ 
able.  If  time  permits,  current  DOD  research  in  long  term 
solution*  could  also  be  mentioned  <37i14-2®t.  Day  five  ends  with 
a  course  review  and  student  critique. 


Chap ter  Six 


CLOSING 


9UMHAftV 

Project  Sold  Strok*  is  a  HQ  USAF  progrM  to  combat  prooltm 
in  Air  Fore*  soHmsti  management.  A  specific  Bold  Strok* 
rtquir— nt  given  to  Air  University  is  to  d*v*lop  a  short  course 
for  senior  officers  and  civilians.  This  paper  atteepts  to 
address  that  requiresent  by  reviewing  th*  documented  problems  in 
the  development  arena  and  conclude  with  a  list  of  recommended 
course  topics. 

In  researching  the  topic  this  paper  noted  various  reports 
have  dealt  with  different  aspects  of  the  software  development 
crisis.  Some  studies  treat  the  issues  within  the  context  of 
command  and  control,  embedded,  or  general  purpose  A DP  systems. 
Some  publications  concentrate  on  contracting,  cost  estimating,  or 
programmer  productivity.  Some  simply  address  management.  This 
paper  tries  to  highlight  most  software  issues  so  students  in  a 
software  development  literacy  course,  under  th*  Project  Bold 
Stroke  program,  may  become  aware  of  the  pitfalls.  Having  assumed 
students  of  varied  backgrounds  but  with  little  software  exper¬ 
tise,  th*  author  argues  for  a  course  length  of  five  days  and 
concludes  with  a  suggested  list  of  topics. 


RE  COHHE  ND A  T I ONS 


Course  Topics 

The  author  suggests  3®  to  4®  percent  of  the  course  highlight 
software  development  problems  in  parallel  with  the  presentat  10c, 
in  chapters  two  through  f -our .  About  half  of  that  time  should  be 
given  to  highlighting  solutions  and  guidance.  A  por 1 1  on  of  the 
course  should  provide  hands-on  eperience  and  discussion  of  other 
Federal  agencies  the  student  could  contact  for  help.  Append  1  A 
contains  a  list  of  topics.  Appendix  B  is  a  r ecommended  student 
reading  list  and  a  start  towards  a  deskset  reference. 


It—  For  Furthtr  Study 

In  developing  this  paper,  several  references  spawned  ques¬ 
tions  and  ideas  beyond  the  scope  of  this  research.  Appendix  C 
contains  a  list  of  items  for  further  study. 


FINAL  REMARKS 

Software  is  the  most  troublesome  current  problem  in.  . 

system  design  and  development.  It  is  the  primary 
reason  why  some  systems  in  existence  or  under 
development  have  not  achieved  their  per iorm^ncm  goals. 

It  is  now  also  the  most  costly  part  of  a.  .  .  system 

and  software  costs  continue  to  grow  while  hardware 
costs  continue  to  decline  (1:33). 

The  Select  Committee  heard  presentations  from  over  300 
representative*  of  97  government,  military  and 
industrial  agencies.  .  .  .  The  briefings.  .  .  covered 

the  original  mode  of  operation  of  the  agencies,  their 
successes,  failures,  and  problems  with  computers.  •  .  . 

The  overall  impression  conveyed  by  these  presentations 
was  one  of  uncertainty  created  by  a  mass  of  detailed 
problems.  ...  It  became  apparent  to  the  committee, 
at  an  early  date,  that  most  of  these  problems.  .  .  were 

in  realitv  symptoms  of  the  more  basic  problems.  The 
evidence  points  to  the  fundamental  problem  of  system 
definition  and  acquisition,  cost  and  complexity,  and 
expertise  <30il0-ll>. 

These  quotes,  written  in  1974  and  1970,  respectively,  sum  up 
much  of  today  s  thin) ing.  Un f or tunate 1 y ,  the  age  of  these 
comments  point  out  the  software  crisis  was  recognired  long  ago. 

That  crisis  has  been  building  tor  years.  Jointly  and  separate¬ 
ly,  the  military  services  and  the  Office  of  the  Secretary  of 
Defense  nave  studied  software  problems  off  and  on  ever  since 
programmable  digital  electronics  began  enter  ing  combat  systems  m 
the  1970,"  <5:49).  A  breaf -through  is  needed  and  Project  B- .  1  d 

Strode  may  be  a  unique  idea  by  foe  using  on  awareness  at  the  top 
through  formal,  Air  Force-wide  programs.  Its  success  will 
depend  upon  support  from  the  same  community  it  will  attempt  to 
educate. 
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APPENDICES 


Appendix  A 


Day  1 


COURSE  TOPIC  OUTLINE 

Course  Introduction  and  Objectives 
Bold  Stroke  Reference  Book 

Introduction  to  licrocomputers 

Hardware  (with  tear-down  model) 

CPU 

Memory 

ROM ,  RAM 
Input  Devices 

keyboard,  Mouse,  Lightpen,  Tablet 
Output  Devices 

Paral lel/Ser lal  Ports,  Printers 
Storage  Devices 

Floppies,  Hard  Disks,  Tape  Backup,  Bubble 
Add-on  Cards 

Software 

DOS 

Word  Processing,  Spreadsheets ,  DB  Managers 

Hands-on  Experience 

Hands-on  Experience  (cont'd) 

Introduction  to  Software  Development 
Life  Cycle  Model 
In-house  Development 
Contract  Development 

Embedded  Computer  Systems 
Embedded  Software 

Avionics  Packages,  Sensors,  Heads-up  Displays 


” «v-v-v 


Day  3 


AFP  700  v«.  8<X*-*er  1  es 


Software  Development  Crisis 

Life  Cycle  Issues  (Chapter  3  this  report) 
Management  Issues  (Chapter  4  this  report) 

Case  Studies  on  the  Impact  to  Feed  mess 

Day  4  Avoiding  the  Pitfalls 

James  Martin  s  Manifesto 

Concept  Development 

Incremental  Design 
Prototypes 

Screen  Generators 

Fourth  Generation  Languages 

ADA 

Con  tr  ac  1 1 ng 

Evolutionary  Method  (BGen  Hirsch) 

Del l verab les 

Project  Oversight 
Costing 
Schedul i ng 

Validation  and  Verification  'Includes  testing' 
Dep 1 oymen t 

Day  3  Or yan i ;a t l ons  for  Help 

AFSC 

At  CC  (SI  SC,  EID,  AFC AC) 

DOD  (NAVCOSACT,  TPADOC) 

GSA 

Software  Engineering  Institute  <SEI' 

Joint  Logistics  Commanders  <JLC)  Initiatives 
and  Computer  Management  Committee 

Rev i ew 

Course  Critique 
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Appendix  C 


ITEMS  FOR  FURTHER  STUDY 


1.  What  are  realistic  possibilities  o-f  automatic  code 
generators?  Will  they  exceed  glorified  report  generators? 

2.  Are  there  differences  between  mainframe  and 
embedded  systems  beyond  hardware  and  procurement  approaches 
(1:313-314)? 

3.  Programming  productivity  is  sometimes  measured  as 
useable  1 ines-of-code  (LOC)  per  man-month.  What  factors 
contribute  to  Japan's  rate  of  3,500  LOC  compared  to  the  US's 
183  LOC  (5:52)? 

4.  It  is  known  this  crisis  has  been  bu-ilding  for 
years.  What  has  prevented  the  DOD  from  attacking  the 
problem? 

5.  If  today's  problems  are  a  function  of  computer 
illiteracy,  is  this  a  temporary  crisis  until  the  younger, 
computer  literate  generation  matures?  (For  example:  every 
academy  student  has  access  to  a  computer.)  Can  a  get-well 
date  be  determined?  What  are  the  impacts  on  readiness  till 
then? 


6.  No  recent  study  of  generalist  versus  specialist  or 
whole-person  versus  technician  was  discovered?  Could  a  dual 
track  ladder  work?  What  career  management  concept  did 
Electronic  Data  Systems  (EDS)  of  General  Motors  undertake?" 

7.  Has  there  been  any  survey  of  Air  Force  satisfaction 
with  computer  support?  If  one  were  done,  could  the  adverse 
impact  of  the  software  crisis  on  user  satisfaction  be 
subtracted  and  valid  feedback  obtained? 

8.  How  can  today's  computer  specialist  keep  abreast  of 
technology?  Where  is  the  Air  Force  headed  and  how  is  that 
information  passed  on  to  planners  so  as  to  glean  from 
today's  computer  advancements  the  ideas  for  tomorrow's 
weapon  systems? 


9.  Is  there  any  mechanism  to  create  an  Air  Force  lobby 
to  de-conflict  congressional  oversight  from  budgeting  and 
acquisition  (41*14)? 

10.  What  will  the  impact  of  artificial  intelligence 
and  fourth  generation  languages  have  on  the  overall  Air 
Force  software  development  and  maintenance  problems? 

11.  Will  ADA,  when  fully  employed,  provide  the 
envisioned  portability  of  software  packages  and  reduce  the 
need  for  some  software  development?  What  problems  are 
associated  with  ADA  (7j — ;  17s — )? 

12.  What  is  the  impact  on  security  with  increased 
contracting  and  of f-the-shel f  buys? 
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